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Brief Summary Text - BSTX (13) : 

Many compilers use a representation called a call graph to analyze an entire 
program. A call graph has nodes representing procedures, and edges 
representing procedure calls. We use the term procedure to refer to 
subroutines, functions, and also methods in object-oriented languages. A 
direct procedure call, where the callee (called procedure) is known at the call 
site, is represented by a single edge in the call graph from the caller to the 
callee. A procedure call/ where the callee is not known, such as a 
virtual -method call in an object-oriented language or an indirect call through 
a pointer, is represented by edges from the caller to each possible callee. It 
is also possible that given a particular (callee) procedure, all callers of it 
may not be known. In that case, the call graph would conservatively put edges 
from all possible callers to that callee. 
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Brief Summary Text - BSTX (33) : 

An alternative embodiment of the method uses a different analysis to 
overcome the write-barrier dependences due to PEIs. In this embodiment, no 
extra parameter is added to procedures. Instead, the analysis to record the 
liveness information of variables at enclosing exception is done at compile 
time, using the call graph representation of the program. The information 
about exception handlers, if any, surrounding a procedure call from A to B is 
propagated to B and to all procedures reachable in the call graph from B 
(representing all procedures transitively called from B) . In this embodiment, 
there is no need to create a specialized version of the procedure. All 
write-barrier dependences related to PEIs that do not have a non- trivial 
enclosing exception handler, are ignored. In the special case where the static 
analysis shows that a procedure cannot have any dynamically enclosing exception 
handler with live variables, those regions of code in that procedure which do 
not have an exception handler block within the procedure, can be viewed as 
write-barrier-free regions. These regions are optimized while ignoring all 
write-barrier dependences. 



Detailed Description Text - DETX (8) : 

Lines 201-236 describe the Initial Program Scan phase. Line 202 builds a 
call graph representation of. the program. Lines 203-210 determine what 
predefined exceptions may be thrown directly by a procedure and represent this 
information in the bit vector Except for that procedure. Lines 225-236 later 
propagate this information interprocedurally using a worklist so that each 
caller includes the list of exceptions thrown by any callee procedure that is 
called by it. Lines 211-216 determine the behavior of each procedure that may 
finally handle an exception not caught by any exception handler. For example, 
in the Java.TM. language, an exception which is not caught by an exception 
handler is handled by executing a special procedure, the uncaughtException 
method of the thread group. Java.TM. also allows user code to override the 
uncaughtException method. Line 213 checks if the default handler is 
non-trivial (as defined by Lines 301-306. If so, EEH.sub.init is initialized 
to 1, which in turn would cause all bits of EEH.sub.c to be initialized to 1 on 
line 218. Lines 217-224 determine which call sites are enclosed by exception 
handlers that catch a specific exception and are non- trivial (as defined by 
lines 301-306) . This information is stored in the bit vector for that call 
site, EEH.sub.c. In a preferred embodiment, this information is propagated 
across procedures dynamically during execution, as described later. 



Detailed Description Text - DETX (26) : 

Line 701 builds the call graph representation of the program. Line 702 
performs an interprocedural analysis on this graph to identify the exception 
handlers that may dynamically enclose each procedure, and is described further 
below. Line 703 loops over each procedure in the program. Lines 704-708 check 
if the code region is not possibly enclosed in a non- trivial exception handler 
for a specific exception type- -if so, all write-barrier dependences for that 
exception type are ignored while performing optimizations. 



Detailed Description Text - DETX (34) : 

An alternative embodiment can save storage by compressing the bit vector to 
1 bit, which would represent any predefined exception. This can be computed by 
performing a bitwise or of the bits in the original bit vector. In another 
variant, an explicit extra parameter may not be required. Instead the single 
bit of information is encoded in an unused bit of an existing parameter. For 
example, the two least significant bits of a pointer field are not required on 
a machine with 4 byte words. Thus, any existing pointer parameter can be used 
to encode this information. In particular, virtual -method calls always pass a 
pointer to the object they operate on, called the this pointer, and thus, this 
parameter can be used to store the 1 bit of information. 
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Detailed Description Text - DETX (35) : 

An alternative embodiment modifies the manner in which the dynamic dispatch 
code is generated during code generation (described currently in line 407) . 
Specifically, when generating the code to determine whether to call normal or 
specialized code, a decision is possibly made at code -generation time using an 
enhanced version of the static analysis described in alternative embodiment 
associated with lines 700-907. In these cases a direct call may occur, 
eliminating the need for dynamic dispatch code (line 407) for that call site. 
The enhanced static analysis additionally computes for each procedure whether 
all call sites to it have a call -path where some bit of an EEH is set to l. 
This information records what will always occur. There are three cases: A. If 
the bitwise and of the statically computed any information (computed by the 
alternative embodiment lines 700-907) for a call site and the called procedures 
bit vector, Except . sub. m, is all zero then all calls can be made to the 
specialized version of the procedure. Thus, the need for dynamic dispatch is 
removed. Instead code is generated to make a direct call to the specialized 
procedure. B. If the bitwise and of the statically computed always information 
for a call site and the called procedures bit vector, Except . sub .m, is nonzero 
then all calls can be made to the normal version of the procedure. Thus, once 
again, the need for dynamic dispatch is removed. Instead code is generated to 
make a direct call to the normal version of the procedure. C. If neither A nor 
B is applicable, then the dynamic dispatch code described in line 407 is 
generated. This static analysis occurs after the Initial Program Scan 105, but 
before the Code Generation phase 109. 



Detailed Description Paragraph Table - DETL (1) : 

201: InitialProgramScan (G) 202: Build call -graph, CallG, of program 
represented by G 203: for each node, p, in CallG do // for each procedure 
204: set all bits of Except. sub. p to 0 205: for each instruction, i, in p do 
206: for each predefined exception, e, that i may throw do 207: set the e bit 
of Except. sub. p to 1 208: end do 2 09: end do 210: end do 211: EEH.sub.init 
= 0 212: for each default handler h that deals with uncaught exceptions 213: 
if isNonTrivialHander (h) then 214: EEH.sub.init = 1; break; 215: end if 216: 
end do 217: for each call site, c, in p do 218: set all bits of EEH. sub. c to 
EEH.sub.init 219: for each exception handler, h, enclosing c do 220: if 
isNonTrivialHander (h) then 221: set the h bit for EEH. sub. c to 1 222: end if 
223: end do 224: end do 225: Set WorkList = enumeration of nodes in CallG in 
reverse topological sort order 226: while WorkList not empty do 227: Get 
first element p and delete it from WorkList 228: for each edge (p, q) in CallG 
do // for each call to procedure q in p 22 9: if Except. sub. p != 
(Except, sub. p. vert line. Except, sub. q) then // " . vertline . " denotes bit-wise OR 
23 0: Except. sub. p = Except . sub . p . vertline . Except . sub . q 231: for each edge (r, 
p) in CallG do // for each caller r of p 232: add r to WorkList if it is not 
already present 233: end do 234: end if 235: end do 236: end do 301: 
isNonTrivialHandler (h) 302: if (handler h does not use a variable visible 
outside the handler other than the exception object and the entry to h is 
post -dominated by a call to system exit or termination of the current thread) 
then 303: return false 304: else 305: return true 306: end if 



Detailed Description Paragraph Table - DETL (5) : 

700: CodeGeneration(G) 701: Build call-graph, CallG, of program 
represented by G 702: Perform EnclosingHandlerAnalysis (CallG) 703: for each 
procedure, m, in program do 704: if (h bit of EnclosingHandlers . sub.m is not 
set and there is no non- trivial local exception handler for exception type h) 
then 705: optimize code ignoring write-barrier dependences for each PEI 
corresponding to h 706: else 707: generate code honoring write-barrier 
dependences for each PEI corresponding to h 708: end if 709: end do 
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